Texturing system

ABSTRACT

A texturing system for use in a three-dimensional graphics system has an input for receiving object data for an object to be textured. Encrypted texture data is obtained from a store a decrypted in a decryption unit. The decrypted texture data generates texture image data for a frame buffer from where it can be output for display.  
     There is also provides a method for producing a software application for use in a three-dimensional graphics system which creates instructions for a software application and creates static texture data for use in conjunction with the instructions. The static texture data is encrypted and provided as encrypted texture data with the software instructions,  
     A protected software application can be distributed to a target device from a distribution device by coupling the distribution device to the target device, transferring target device identifier data from the target device to the distribution device and using the target device identifier data in the distribution device to generate encryption definition data specific to the target device. The protected software application and encryption definition data are then transferred to the target device.

[0001] This invention relates to a texturing system for use in athree-dimensional graphics system. It also relates to a method ofdistributing protected software applications.

BACKGROUND OF THE INVENTION

[0002] Computer graphics applications, in particular computer games, canbe very expensive to develop. Unfortunately, they are also a populartarget for software pirates, possibly because of the number of potentialusers. In the past, piracy was usually partially limited by supplyingthe application on a physical medium, e.g., either a ROM cartridge or a‘difficult to copy’ disc, or by shipping a physical key, e.g. dongle. Itis envisaged, however, that software will increasingly be soldelectronically, e.g. downloaded from the Internet or from a ‘point ofsale’, POS, terminal in a shop. This lack of a physical medium wouldthus potentially make illegal copying a far simpler task unless othermeasures are taken.

[0003] The protection of software against piracy has relied on severaltechniques in the past. One such technique is the use of a difficult toreplicate physical medium for storage of the software application. Forinstance, some computer games console manufactures have used “Read OnlyMemory” (ROM) cartridges, or proprietary variants of common media suchas higher density CD ROMs for which no off-the-shelf duplication toolsexist.

[0004] An alternative technique often used for personal computers is touse standard media, such as floppy disks or CDs, but deliberately‘damage’ them in small areas during manufacture using, say, a laser. Theapplication software then contains instructions to check that thesupplied storage medium contains these errors. An off-the-shelf floppydrive or CD-Rom ‘burner’ would not be able to reproduce the error on themedium. Although the checks for the errors can be hidden within thesoftware to a certain extent, given sufficient time a determined crackercan locate them and produce a modified version of the application withthe checks removed. This ‘cracked’ software could then be stored and runusing off-the-shelf media.

[0005] Another method of protecting the contents of the software frombeing modified would be to use a ‘secure’ CPU which could encrypt alltransfers to and from external memory. Such processors, however, are notcommon and this may not be a viable option for the manufacturer of acomputer graphics device. Furthermore, on its own this does not preventcopying of the application, only its modification.

[0006] Some devices, such as ethernet adapters and some computers, areconstructed with an in-built unique identifier. We have appreciated thatthis identifier could be used to customise software so that it runs ononly one machine. Again, unless other steps are taken, this would beopen to abuse by modification of the software that removes the checks.

[0007] The present invention in particular deals with systems andapplications doing 3D computer graphics rendering.

[0008] A typical known environment is illustrated in FIG. 1a. Here a CPU1 is connected to memory 2 that would contain the application code anddata structures. The application would typically respond to user input3. The description of each 3D image, typically composed of triangleswith parameters for application of image, or texture, data is generatedby the CPU and this object data is sent to the rendering subsystem 4.This would use texture data stored in memory 5 to produce image datawhich would be constructed in a framebuffer in memory. The finishedimages would then be sent to the display system 6. In some systems,memory units 2 and 5 might actually be the same physical memory.

[0009] The known 3D rendering system4 is now described in more detailwith reference to FIG. 1b. The rendering system 4 consists of a unit 7receiving polygon data. These polygon data are sent either individuallyor in batches to the rasterization unit 8 which determines which pixelsin the final image are affected by which polygons and what colours toassign to the pixels. As part of this process, texture data must beaccessed 9. This involves converting numerous requested textureidentifiers and pixel coordinate positions into colour values and mayrequire accesses to the 3D rendering system's memory via a memorycontrol system 10. This memory control system would also handleframebuffer read and write requests from the rasterization unit 8.Finally, the display control system 11 would transfer finished imagesfrom the memory to the display device.

[0010] The aim of the invention is to ameliorate the problems associatedwith the known distribution techniques. In accordance with the presentinvention in a first aspect there is provided a texturing systemaccording to claim 1. Preferred features of the texturing system aredefined in dependent claims 2 and 3. Requiring the encrypted statictexture data to be decrypted before it can be applied to the object dataprovides a means of protecting an application by making it difficult tocopy the texture data in a way in which it could be used by anotherdevice to run the same application.

[0011] In accordance with a second aspect of the invention, there isprovided a method of applying texturing to three-dimensional graphicsdata according to claim 4. Preferred steps in the method are defined independent claim 5.

[0012] In accordance with the present invention in a third aspect, thereis provided a method of producing a software application according toclaim 6. The software application is protected by the encryption of thestatic texture data so that only authorised devices can decrypt thestatic texture data and run the software application. Preferred featuresare defined in dependent claims 7 and 8.

[0013] In accordance with a fourth aspect of the invention, there isprovided a method of distributing a protected software application froma distribution device to a target device in accordance with claim 9.

[0014] In accordance with a fifth aspect of the invention, there isprovided a 3-d graphics device according to claim 10.

[0015] We have appreciated that many of the textures used by anapplication, especially games applications, will be created at the timethe application is written. For the purposes of this patent, these willbe referred to as static textures. Other textures may be produced whilethe application is running and these will be referred to as dynamictextures.

[0016] The aim of the invention is to make the widespread duplication ofgraphics software, in particular games software, difficult. It does thisthrough a combination of protection circuitry within the renderinghardware and protection of the static texture data, rather than rely onobfuscation of the software, use of a protected CPU, and/or use of aproprietary storage medium. The invention resides in the realisationthat by encrypting static texture data and controlling decryption of thetexture data associated with a software application, the software may beprotected from unauthorised use The invention concerns a method ofadapting computer graphics hardware with additional software productionsteps to inhibit widespread copying of such applications.

[0017] The system presented relies on the fact that a reasonableproportion of the computer graphics application, in particular acomputer game, is static texture data which is prepared during theapplications development. To protect the application, the standard 3Drendering hardware system is modified in five main ways. Firstly, eachrendering chip has a unique, or at least very infrequently repeating,identification code embedded in it. Secondly, a set of secret keys isbuilt into the silicon of the rendering chip and made virtuallyimpossible to access. Knowledge of certain secret keys are then releasedonly to trusted parties. Thirdly, some number of each application'sexternally stored textures are encrypted during development and are onlydecrypted within the 3D rendering chip by the texturing system duringthe rendering processes. Fourthly, the encrypted static textures aremarked with a secure checksum so that rendering can be made to terminateif invalid texture data is supplied. Finally, the software deliverysystem is also modified so that it can modify or ‘tailor’ the softwarefor a specific target device on which the application is to run.

[0018] It should be noted that dynamic textures, i.e., those generatedby software whilst the application is running, are notencrypted/protected. If a symmetric (i.e. private key only) cipher wereused, this would require storing the key in the application thusexposing it to a determined software pirate. An alternative would be touse a public/private key system, however, at present these are muchslower, and so the time to encrypt the texture would make the techniqueundesirable in a real time system.

[0019] An embodiment of the invention will now be described in moredetail with reference to the accompanying drawings in which:

[0020]FIG. 1a is a block diagram of a known 3-d graphics renderingsystem;

[0021]FIG. 1b is a block diagram showing further detail of the system ofFIG. 1a;

[0022]FIG. 2a is a flow chart showing the steps involved in theproduction of a software application using encrypted texture data;

[0023]FIG. 2b is a flow chart showing the steps involved in modifying asoftware application for transfer to a target device;

[0024]FIG. 2c is a flow chart showing the steps taken by the targetdevice to allow the modified software application to run;

[0025]FIG. 3a is a flow chart showing generation of a security checksumand encryption of the texture data;

[0026]FIG. 3b is a flow chart showing more detail of the steps involvedin the generation of the checksum;

[0027]FIG. 4 is a flow chart showing generation of a Sales Key;

[0028]FIG. 5 is a block diagram showing a texturing system according toan embodiment of the invention;

[0029]FIG. 6 is a flow chart showing the steps performed by the keyproduction unit of the texturing system; and

[0030]FIG. 7 is a diagram showing the steps performed by the productioncontrol unit.

DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

[0031] In a preferred embodiment, the protection system would consist ofthree main processing phases as illustrated in FIGS. 2a to 2 c. Thesewould be the production (or development) phase 20 which occurs duringthe authoring of the software, an optional ‘point of sale’ phase 21 thatoccurs when the software is purchased electronically, and theruntime/rendering phase 22 which takes place when the software is run onthe device.

[0032] The production phase further consists of the standard applicationdevelopment steps 23, and two new steps. The first is to choose(preferably via random means) an application specific encryption key 24,which will be referred to as AEK, and a second step 25 whereby the ismajority of the static textures, i.e. those textures which are simplyloaded into the texture memory and not otherwise modified by applicationsoftware during the running of the application, are check-summed and areencrypted by means of the AEK. In a preferred embodiment, the encryptionsystem would be a private key system, and for security reasons, the AEKin preferred embodiments would be at least 64 bits in size.

[0033] The ‘point of sale’ phase 21 applies to the cases where theapplication is supplied electronically (i.e. no mass-produced physicalmedium is used). The first step, 26 is to request the target device'sunique (or near unique) identifier, DevID. The next step 27 is tosecurely combine the DevID, the AEK, and one of several secret keysembedded inside the rendering chips to produce a sales key, SAK, whichis specific to the pairing of that application and the target renderingdevice. The final step 28 is to download the entire application data,including its textures encrypted with the AEK, to the target device,along with the SAK, and an index for the secret key that was used instep 27.

[0034] If the point of sale phase described below is not be used, forexample if the application is to be provided on a physical medium ratherthan downloaded, then two options are possible.. In the first, aninbuilt ‘set-up’ program asks the owner to contact, for example via afree phone number, a support operator who would ask the user for thedevice's serial/identification number and in return supply a Sales Key.This key would then be inputted by the owner and saved by theapplication (typically in removable memory units) for future executionof the application. Alternatively, a small subset of the set of embeddedsecret key identifiers could have the side effect of ‘replacing’ theinternal device identifier, DevID, with a known constant value thusenabling identical copies of the mass produced media to run on anydevice.

[0035] The run-time rendering phase 22 requires that the applicationsupplies the SAK and the internal secret key to the rendering hardware29. The rendering hardware reverses 30 the combination steps 27 appliedin the point of sale phase by using the internal key, DevID and SAK toretrieve the AEK. During rendering 31 the protected textures aredecrypted on-the-fly using the AEK. In a preferred embodiment of therun-time rendering phase 22, a number of protected textures are sampledand the checksum verified.

[0036] A preferred method for the generation of the security checksumand encryption of the texture data 25 will now be described withreference to FIG. 3a. Each static texture 40 is supplied and aper-texture checksum is generated from the first ‘N’ words 41 of thetexture. The choice of ‘N’ is a compromise between the level of securitydesired and the time taken to test the validity of the texture. In apreferred embodiment, this would be the first 4 words where the wordsize would be 64 bits, but other combinations could be chosen. Thechecksum function could be a simple operation such as the summation,modulo 2⁶⁴, or a trivial bit-wise XOR, i.e. exclusive OR, of the datawords.

[0037] The checksum is concatenated with the entire texture, and theresult is then encrypted 42 and output 43. The encryption step 42 isdescribed in more detail in FIG. 3b. In step 44 blocks of datacorresponding to the width of the block cipher algorithm 45 are issuedto the encryption algorithm. An example of a suitable block cipheralgorithm could be one of the current NEST “Advanced EncryptionStandard” candidates, such as “TwoFish”, or even the earlier Triple DESstandard.

[0038] The texture is effectively encrypted in ‘Electronic CodeBook’, orECB, mode, using the AEK 46. To improve security in a preferredembodiment, the input values would ‘salted’ 47 with their positionoffsets relative to the base of the texture using an XOR operation. Forexample, the J^(th) block of data from the texture could be XORed withthe binary representation of the number J prior to encryption. Thishelps obscure the contents of the texture and increases the difficultyof code book based attacks. Note that many more advanced cipher modes,for example cipher block chaining, CBC, are not suitable for texturingas they do not permit random access of the pixels within the encryptedtextures.

[0039] The production of the sales key 27 is illustrated in FIG. 4. Thisis done by taking the Device ID, DevID, 50 and the AEK 46 and combiningthem 51 using an easily reversible operation, to produce encryptiondefinition data as an intermediate result 52. In a preferred embodimentthis combination operation could be an addition or a bitwise exclusiveOR, and the output would be at least 64 bits. The operation isreversible in the sense that given the Device ID and the intermediateresult, it is simple to derive the AEK.

[0040] The encryption definition data is then encrypted 53 with a blockcipher using a secret key 54 a copy of which will be embedded in orderivable within every rendering chip. This secret key is never publiclyrevealed but is known to the distribution device or sales tool. In apreferred embodiment a plurality of secret keys would be embedded in theevent that the current secret key was compromised. Alternatively, apublic key system such as RSA (U.S. Pat. No. 4,405,829) or akey-exchange system such as Diffie-Helman's (U.S. Pat. No. 4,200,770)could be used. The public key is used in the sales tool and the privatekey would be embedded within the rendering hardware.

[0041] The encrypted result 55 is used as the sales key, SAK, which isexported with a copy of the application.

[0042]FIG. 5 illustrates the modifications that are made to therendering unit 4 that was originally described in FIG. 1b. The modifiedunit contains a Key Production Unit 30 that accepts the Sales Key, SAX,and the identifier for the internal secret key, and reverses the stepsdescribed in FIG. 4. This produces the internal copy of theapplication's encryption key 71. This key is supplied to the texturedecryption unit 72 which decrypts texture pixels needed by the textureaccess unit 9. It should be noted that, with the hardware thusdescribed, if an invalid key were supplied, the textures on the polygonswould appear as random noise.

[0043] In addition, a protection control input unit 73 would receive acommand word or words from the application running on the CPU 1, whenthe application starts executing. To prevent behaviour being compromisedby deliberate modification of the application, these commands will havebeen encrypted with the internal AEK 71. The unit 73 decrypts thecommand and supplies it to the Texture Validity Check unit 74. Whilsteach scene is rendered, this unit samples some number of the protectedtextures, via the texture access unit 9, to test that the storedchecksum matches a checksum computed from the start of the texture data.Actions determined by the command supplied by 73 can be taken if thesematches fail. The choice of actions would depend on the target market ofthe device, but a choice of likely actions could include shutting downthe rendering chip, sending an interrupt to the CPU, and replacing the‘textures’ with a flat shaded mode which could be used for demonstrationpurposes.

[0044] In a preferred embodiment, there would be a delay, determined bya clock counter, before an action would be taken by the validity unit74. This makes attacks based on repeatedly guessing a less restrictiveencrypted command infeasible due to the time taken.

[0045] Furthermore, in a preferred embodiment, there is a memoryencryption/decryption unit 75 positioned between the memory controller10 and the memory 5. This unit is intended to make reverse engineeringof the original contents of the static textures more difficult assumingan attack involving re-writing the application.

[0046] The behaviour of the key production unit 30 will now be describedin reference to FIG. 6. The application supplies the identifier for thesecret key that was used by the sales application in combination step27. This accesses a secret key table or function 81, that returns theactual secret key 82. In a preferred embodiment, the secret key would beat least 64 bits in size assuming a symmetric cipher is used. A muchlarger key would be needed if a public/private key system were employed.The chosen secret key 82 is then used to decrypt the sales key 55, whichis also supplied by the application, using the decryption function 83.This function must be the inverse of encryption step 53. Theintermediate result 84 which is identical to that of intermediate result52, is then supplied along with the Device ID 86 to a separation or‘uncombine’ operation 85 which is the reverse of combination operation51. The result is the internal Application Encryption Key 71 and isidentical to that chosen in step 24 and subsequently used in 46. Thepreferred embodiment has a choice of several secret keys so that, in theevent of a security breach in the point of sale application, there is afall-back position so that future releases might not be compromised.

[0047] The system must also protect the instructions issued to therendering system from the application with regard to its behaviour withthe checking of valid textures. This is done within the protectioncontrol unit (73), and the operation is now described in reference toFIG. 7. The application supplies one of several legal instructions whichhave been encrypted during the development phase with the AEK 24, andthis is stored in the Encrypted Control Word Register 90. To inhibit therandom guessing of a less restrictive control word, the register in apreferred embodiment should be at least 64 bits wide. The contents ofthe register are then decrypted 91 using the internal copy of the AEK71. The decrypted results are then checked to see if they match one ofthe small set of valid commands 92. An invalid command will result in avery restrictive command being sent to the validity check module 74which, in a preferred embodiment, would bring the rendering to a haltafter a delay.

[0048] It should be noted that when the circuits are implemented insilicon that the areas controlling the protection, and in particular thesecret keys, should not be accessible by register test scan chains.Furthermore, it is important that the secret keys not be released to thepublic.

[0049] With respect to the above description, it is to be realised thatequivalent apparatus and methods are deemed readily apparent to oneskilled in the art, and all equivalent apparatus and methods to thoseillustrated in the drawings and described in the specification areintended to be encompassed by the present invention. Therefore, theforegoing is considered as illustrative only of the principles of theinvention. Further, since numerous modifications and changes willreadily occur to those skilled in the art, it is not desired to limitthe invention to the exact construction and operation shown anddescribed and accordingly, all suitable modifications and equivalentsmay be resorted to, falling within the scope of the invention.

[0050] It should be noted that the features described by reference toparticular figures and at different points of the description may beused in combinations other than those particularly described or shown.All such modifications are encompassed within the scope of the inventionas set forth in the following claims.

[0051] For example, different techniques for encrypting the texturedata, such as the public/private key system, could be employed.

1. A texturing system for use in a three-dimensional graphics system,the texturing system comprising: an input for receiving object datadescribing an object to be textured; a store for storing encryptedtexture data for applying to an object to be textured; a decryptionunit, coupled to the store, for decrypting the encrypted texture data; aframebuffer, coupled to the input and to the decryption unit, forapplying decrypted texture data to object data to generate texturedimage data; and an output, coupled to the framebuffer, for outputtingtextured image data for display.
 2. A texturing system according toclaim 1, wherein the input is configured to receive encryption keyidentification data identifying the encryption key used to encrypt thetexture data, the texturing system further comprising a key productionunit, coupled to decryption unit and to the input, for generating theencryption key from the encryption key identification data, whereby thedecryption unit uses the encryption key to decrypt the encrypted texturedata.
 3. A texturing system according to either claim 1 or claim 2,wherein: the store is configured to store encrypted texture and checksumdata; the decryption unit is configured to decrypt the encrypted textureand checksum data and separate the data into texture data and checksumdata; and the system further comprises a protection unit, coupled to thedecryption unit, for monitoring the checksum data and for adapting theoutput of the texturing system if the checksum data does not matchcontrol checksum data.
 4. A method of applying texturing tothree-dimensional graphics data, the method comprising the steps of:storing encrypted texture data for applying to texture an object;receiving object data describing an object to be textured using storedtexture data; accessing and decrypting the encrypted texture data;applying the decrypted texture data to the object data to generatetextured image data; and outputting the textured image data for display.5. A method according to claim 4, further comprising the steps of:receiving encryption key identification data identifying the encryptionkey used to encrypt the texture data; calculating the encryption keyfrom the encryption key identification data; and using the encryptionkey to decrypt the encrypted texture data.
 6. A method of producing asoftware application for use in a three-dimensional graphics system, themethod comprising the steps of: (a) creating instructions for a softwareapplication; (b) creating static texture data to be used by a device inconjunction with the instructions to run the software application; (c)encrypting the static texture data using an encryption algorithm; and(d) outputting the encrypted texture data and software instructions asthe software application.
 7. A method according to claim 6, comprisingthe additional steps of; generating checksum data for the static texturedata; combining the checksum data and the static texture data; andwherein step (c) is modified to encrypt the combined checksum and statictexture data.
 8. A method according to claim 1, wherein the checksumdata is generated from a first plurality of words selected from thebeginning of the texture data.
 9. A method of distributing a protectedsoftware application from a distribution device to a target device, themethod comprising the steps of: coupling the distribution device to thetarget device; transferring target device identifier data from from thetarget device to the distribution device; using the target deviceidentifier data in the distribution device to generate encryptiondefinition data specific to the target device; transferring theprotected software application and the encryption definition data fromthe distribution device to the target device for subsequent use by thetarget device to enable the protected software application to be run,10. A method according to claim 9, wherein the encryption definitiondata is itself encrypted to form a Sales Key and wherein the Sales Keyis transferred with the protected software application to the targetdevice.
 11. A 3-d graphics device for running software applicationscomprising instructions and encrypted texture data, the devicecomprising: a CPU for running a software application; a memory, coupledto the CPU, for storing a software application; a display for displaying3-d graphics generated by running a software application; and atexturing system according to any of claims 1 to 3, the input of thetexturing system being coupled to the CPU and the output being coupledto the display.
 12. A 3-d graphics device according to claim 11, whereinthe texturing system is configured to store a device identifier for useby a distribution device.
 13. A distribution device for distributing aprotected software application to a target device, the distributiondevice comprising: a receiver for receiving target identifier data froma target device; a combiner, coupled to the receiver, for generatingencryption definition data from the target identifier data and anapplication encryption key; and an output for outputting a protectedsoftware application and the encryption definition data to a targetdevice for use by the target device to enable the protected softwareapplication to be run.
 14. A distribution device according to claim 13,further comprising: an encrypter, coupled to the combiner and to theoutput, for encrypting the encryption definition data to form a SalesKey, wherein the output outputs the Sales Key and the softwareapplication to a target device for use by the target device to enablethe protected software application to be run.
 15. Apparatussubstantially as hereinbefore described with reference to any of FIGS. 2to
 7. 16. A method substantially as hereinbefore described withreference to any of FIGS. 2 to 7.